Jason Knight  0:00  
Outcomes, outputs, outputs over outcomes, outcomes over outputs, outputs over outputs. We all know the right answer, but how do we get the rest of the business to come along with us? Tonight, we're going to find out. Speaking of outcomes, making progress in your product career can be tough. But luckily, we have a great community of peers who can help us. I've been trying to do my part, but I'm merely one insufficient man. So I've helped set up My Mentor Path, a new free mentoring platform for product managers and product leaders, where you can get the support you need to grow in your career, you can head over to my https://www.mymentorpath.com, where you can sign up to be a mentor, mentee or both. You can check the show notes for more details. Now, we can't talk about outcomes without bumping into OKRs and my guest tonight has strong opinions and war stories about using them as a gateway drug to agility and good product management. So stick with me as I play the Jesse to his Walter White, on One Knight in Product.

Jason Knight  1:07  
So my guest tonight is Jeff Gothelf. Jeff's a forever employable designer, consultant and co author of some books you've definitely heard of, including Sense & Respond and Lean UX. Jeff used to work in a circus, which I'm presuming has given him plenty of relevant experience for dealing with some of the companies I've seen out there. And as a trained kickboxer is aiming a roundhouse kick to the midriff of poor product practices, hoping to get companies to build great products and the cultures that build great products by focusing on outcomes, hopefully without a red nose in sight. Hi, Jeff, how are you tonight?

Jeff Gothelf  1:35  
I'm doing great, Jason, thanks so much for having me.

Jason Knight  1:37  
No problem. It's good to have you here. And I do have to ask what it was you did at the circus as well, because I'm assuming that you weren't like a juggler or a unicycle guy. But what are you doing in that circus?

Jeff Gothelf  1:47  
I mean, you shouldn't assume right? I have many, many, many hidden talents. But no, my running joke now and it's been 28 years since then, which is soul crushing to even say out loud. But my running joke for years was that I was the bearded lady. Now, if I showed you pictures of myself from 1995, you could see that I actually had hair. It was long. I had a beard. But no, the truth is I was the sound and lighting technician for the circus.

Jason Knight  2:17  
Oh, there you go. Yeah, sounds like an important job. You've got to get those who to noises going exactly at the right frequency and everything like that. 

Jeff Gothelf  2:25  
It was asuper important job. It was really difficult. But it was, it was an adventure to say the least. 

Jason Knight  2:31  
There you go. We'll get the pictures later. So back to the present day, you're the founder of gothelf.co, your own consultancy, you're the co founder of Sense and Respond press, publishing beautiful books about product and product design. But how are you specifically spending in your day to day at the moment, like, what are you working on at the moment?

Jeff Gothelf  2:49  
So these days, I'm doing two things, primarily one is delivering training. And the training I've been doing a lot of lately is focused on primarily three things. One is lean UX. So to this day, Lean UX has been out in the market for a decade, which is unbelievable. 

Jason Knight  3:03  
Oh, wow. 

Jeff Gothelf  3:04  
Third Edition has been out for about a year, every five years or so they seem to give us a chance to rewrite it. I'm super grateful for that. Because it does, it does keep getting better. That's that's the truth. So I'm teaching Lean UX. I'm teaching product management or so a leaner form of Product Management. And I'm teaching OKRs. And I'm doing that through training and workshops, and speeches. I do a lot of speeches, a little bit of coaching and some advising as well with some some early stage startups. And then the other thing I'm working on this year, and it's kind of a big project, again, speaking of books, is Josh Seiden, and I my longtime co author, collaborator and friend, yep, Josh and I are writing a new book together. And it is an OKR book. It doesn't have a title quite yet. But we have started that process. And we hope to get the book published by the by q4 this year. That's the goal.

Jason Knight  3:57  
That's the outcome. And the key result all in one little statement there. But I was gonna ask you about the book later. So you've preempted that question, we're going to talk a bit more about OKRs in a bit, which is good. But before that, I wanted to talk a bit about that to our day to day work. So with gothelf.co you say you're currently working with companies of all sizes, helping them get lean. But obviously, it's traditionally considered quite tricky to get lean with bigger companies, bigger enterprises. So do you feel that you've had a lot of success with these bigger companies? Or do you feel that you have the most impact on these sort of small to medium companies where maybe they're a bit more receptive?

Jeff Gothelf  4:29  
It's a really good question. I think it really depends on where I come in, in the organisation. And I've come in at various levels across the, you know, kind of up and up and down the ladder, if you will. If I come in in the middle, then I feel like I have very tactical, local impact the team that hired me, a couple of adjacent teams, maybe a particular business unit, but sort of broad corporate influence, probably not right. Sometimes I come in at the sea level. And what's interesting is that the more Most Effective engagements that I've had, I've come in at the chief HR officer level. Okay? No, no, really. And because those folks are those folks are in charge of learning and development. And so when I'm brought in that level, at least the the impact, or at least the the, the access that I have for the organisation is much broader. And because it comes from on high, right, it comes from a C level executive, there is a lot of interest, there's a lot of uptake, there's a lot of listening, that takes place. And so the influence is much, much broader. It's still, you know, you can't take a company with 50,000 people and assume that with a few workshops, even with a few 100 workshops, you're going to transform that organisation, but you can plant the seeds, and you can get folks thinking about things in the right direction. And so really, depending on where I come in, changes the level of impact with medium sized companies, you stand a slightly better chance, but really, the culture is so baked, even like in a 500 or 1000 person company. Yep, still surprises me how much resistance there is to change. And so yeah, and so the best, the best chance we get is to plant these seeds early. But that's less of the work that I do. Yeah, it's

Jason Knight  6:07  
interesting, because I've had discussions with some consultants recently who say that exactly what you said, like getting in early, have the most impact, but also they've got no money, so they can't afford to get people to come in and do it. But I think also you were talking about the size of the company, I've seen very small companies like your 50 to 100 Mark that still have that surprisingly, baked in culture, that's kind of the the sum total of every bias and work in practice, that every single person that's got into the company has kind of bought with them. So I do think it's really interesting, like how soon it starts to become difficult to change. But yeah, obviously, still smaller is better in those situations. But I also think it's really interesting, talking about that sea level thing, because there's this big thing in the product, Twitter, and all of those places, like our job titles don't matter. It's all about the impact that you make. And obviously, I fundamentally believe that but at the same time, sometimes job titles do seem to matter. Because like you say, coming in as a chief HR officer, or Chief Product Officer or something like that, it almost sets the scene for the type of discussions that you're going to be having with people or like the level of authority that that's given you. So do you feel that it's fair to say that job titles kind of do matter a little bit in those sort of situations, especially when you're transforming?

Jeff Gothelf  7:14  
I believe, like you that ultimately they shouldn't matter. But they absolutely do that. And they matter in a couple different ways, right? They matter in who brings you in number one, that gives you as an external consultant that gives you a lot of authority, and credibility, or lack thereof, depending on how you're brought in. I mean, I was a UX designer for a decade before I started shifting towards product work and more entrepreneurial work. And for a long time, and really still to this day, a lot of UX folks try to bring me in. And sadly, you know, they are not in a position to do that. So I've always got to say, well, who's who are we going to talk to you, which who's the manager that we report into and that type of thing. That said, it does matter? Who comes to these as well. But job titles show up to these trends? Because a lot of folks think, well, this isn't for me, right? This is a Lean UX class. It's for UX designers. This is a product management class, it's for product managers. It's not for me. And I think it's worth noting to these folks that that's really where it becomes detrimental. I think these folks get hung up on their job titles. And because of that they discard opportunities to broaden their understanding of how product gets built, how successful collaborations take place, and how you're ultimately successful. I think it's like if it's if it was a highly technical training on how to write a specific type of code or or use a particular technology, or implemented a particular way. Okay, if you're not technically oriented, or technically minded, I understand skipping that, right. But if there was a high level intro to that technology that said, Listen, this is a new thing that's available to us. And it could make our lives a whole lot easier. It shouldn't matter that your job title is designer, product manager, engineer, everybody should be attending that. And the same is true for product managers, product management classes, Lean UX classes, etc.

Jason Knight  8:56  
That's interesting, though, because you've touched on your background, as a designer. And I think it's fair to say that not all designers seem on board with some of this Lean and Agile stuff. I've certainly had some heated discussions in the past where we've been talking about like, moving in increments, and iterating, and all of that stuff. Have you personally always had kind of a lien mindset throughout your career? or was there some kind of inflection point or epiphany at some point where you just sat there and said, actually, this will make sense to me? 

Jeff Gothelf  9:20  
No, no, I definitely didn't start out that way. I was very, you know, that's traditional sort of very waterfall, you know, make the design requirements document kind of designer. That's That's what that's how I learned the job,

Jason Knight  9:33  
Is that, like, an agency thing. 

Jeff Gothelf  9:34  
No, from agency and in house, I mean, I worked at America Online for a few years. And we wrote documents, that was the business, the business was the documentation business. I'd spent, you know, nearly a decade doing that. And I was looking ahead to sort of the neck with what's the next decade going to be and I'll be honest with you. I had a real moment where I said, Look, if the next decade is just writing more of these documents, and Having at least half of them. So when I was writing design requirements documents, and you know, wireframe decks and that type of thing, on a good day, on a good day 50% of that document got thrown away. Yep. Right, that was a good day, which means that on an average day 6070 75% of that document was getting thrown away. And so when I'm looking ahead to the next 10 years of my life and my career, the question is, do I want to spend the next 10 years creating these documents, and generating 75% of them as waste? And the answer was no, right? No way, I was gonna take another decade of my life to continue working this way. It's not that I didn't love the work. I didn't, I love the design work. I love the UX challenges, I loved the whole thing of making things accessible and easy and obvious, and organised. But there was just no way that I was going to continue this particular way. And that was nice, because that was roughly around the time when the popularity of agile was beginning to rise. Eric Ries was starting to talk about Lean Startup, still early days, you know, still before the book type of thing. And so these ideas that are percolating and started to make a lot more sense that a great this makes a lot of sense. The focus is still heavily engineering, how do we start applying this stuff to design and then ultimately product as well?

Jason Knight  11:18  
Yeah, it makes a lot of sense. And I think it is really interesting, kind of following the trends that are coming up in the industry as well. And kind of having your mind opened up to different ways of working. It also makes me think of when you're talking about sort of 75% Waste of try to come up with some kind of waterfall offsetting scheme or something like the carbon credits, where you can sit there and somehow get back some of the goodwill somehow for all of the work that you've had to throw away. But you know, maybe we need to work on that a little bit.

Jeff Gothelf  11:44  
I want the time back. Well, I want that part of my, my life back. That's what I really want.

Jason Knight  11:51  
But you've written or you've co-written, and a bunch of books. 

Jeff Gothelf  11:54  
Yeah. 

Jason Knight  11:54  
With Josh show, you've written Lean UX, you've been sent to respond.. Both books that probably a lot of people that are listening to this have heard of trying to persuade people to use, I guess, a lot of the principles that you're currently training. So talk about being lean, obviously, the power of discovery, all the good stuff that I think we'd find it quite hard to find product managers that would disagree, at least in principle, with doing those things, even if we're not doing all of them yet. But I was also really interested in a much shorter book you wrote on your own, which is lean versus agile versus design thinking. And I have to ask all these really verses, or can we all get along?

Jeff Gothelf  12:28  
We definitely can't get along. And I think that in hindsight, and I've thought about this last since I published that book is the verses aspect that was probably the wrong part of the title should have been. And I really like at first, that book came about from a question, a question from a client, the client that I happen to know particularly well, he was, he was a friend and a client, and he was running a b2b product team inside a large bank. And he had basically positioned the question to me that way, he's like, you know, I'm teaching my product folks lean on teaching my designers design thinking, I'm teaching my engineers agile, and they seem to be in conflict with each other. It's like lean versus agile versus design thinking. And that's what kind of the lightbulb clicked for me. But the whole purpose of that book was, in fact, to state that, yes, we can indeed get along. But fundamentally, the philosophies that underlie all of these ideas are the same. That there's there's tremendous risk, unpredictability and uncertainty, particularly in digital product development, that understanding our customers working in shorter cycles, making decisions based on evidence, and continuously improving by changing a definition of done from sort of making a thing to having an impact, or changing an outcome is the fundamental measure of success. And look, all of these ideas, design thinking, and agile and lean startup and lean UX and whatever else, right? They're all coming at it from the same philosophy just with different words, and different tactics and different cadences. And, and so that's where it really gets confusing, but 100% All of these ideas have the same goal. And yes, we can definitely get along.

Jason Knight  14:03  
Good. We should be getting along. But yeah, Lean and Agile are two things that probably most people at least think they understand. They're fairly defined. There's manifestos and books. And well, obviously, there's books about design thinking too. But he also called out in the book that there's not really one definition of design thinking, and it's maybe a bit woolly or fuzzy, and everyone's got their own kind of take on it. So I'm gonna put you on the spot and ask you to define design thinking in your own words.

Jeff Gothelf  14:30  
Absolutely. That and I think like I think I do would disagree that they think they've done they feel like they've done a good job defining design thinking, but generally speaking, the way that I see it is design thinking is taking the designers toolkit. So the way that designers have been solving problems for decades, and applying it to business problems. That's it. That's what design thinking is, right. And most folks I think listening this are probably familiar with that ideal honeycomb diagram for design thinking that talks about the various phases of a word I deviate, prototype, test, learn iterator, whatever it is, I can't remember all the pieces. But the short of it is that those should sound familiar to you, right? Like, that's how designers have been doing design work for decades. Why can't we take those same ideas and apply them to business problems? And that was that was ideas whole pitch, that's design thinking, whole pitch. And it makes a tonne of sense because it's a customer centric view of the work, not a product centric, not a feature centric view of the work.

Jason Knight  15:32  
No, absolutely. But one of the things I liked about the book, that's something that's been coming up and a few conversations I've had recently is the idea that it's less about the specific frameworks or the books or whatever that you read, but it's all about the principles, and you just touched on that yourself as well, you called out a couple, no actually 10 principles in that book that you boil it down to, I'm not going to read them all out, because you know, got other things to do in our lives. But I wonder if there's like one main mega meta principle that overrides all our sin is kind of the fundamental, ultimate truth of why we should, or what we should be doing like is that one principle that you think stands above the rest

Jeff Gothelf  16:09  
100%, it's managed to outcomes. To me, that's, that's the one that my visual metaphor, and I've yet to be able to sell this successfully to anyone, or actually even make a little sketch of it, my visual metaphor is that it's the hinge. It's the hinge that all of this sort of pivots on. Right? If an organisation can make the mindset shift, and understand that the measure of success for our work is outcomes, measurable, hopefully positive changes in the behaviour of the people that we serve in the behaviour of humans, then everything else flows from that. And that's to me, that's the key, right? Because there is there's there's very little humility, there's very little room for improvement or iteration or learning in a feature centric way of working, right. Yeah, build me this thing, make it red, ship it by Friday? Not a whole lot of flexibility or agility or really bandwidth, for course, correction, or humility in that right? How do we know that it should be red? How do we know it should be this feature? Why Friday, right? All of these things that generally, people don't ask, but if you said, Listen, what we're trying to do is make sure that folks can reduce the time that it takes to apply for a credit card from five days to five minutes. Right? All of a sudden, we fundamentally, that's an outcome, right? It's it's a, it's a meaningful change in the behaviour of the people that we serve, right. So instead of taking it five days to apply for a credit card, it's going to take you five minutes, right? All of a sudden, we've created not only a goal and outcome based approach to this, but we've created the space for learning, iteration and improvement to take place, because I haven't told the team, build it this way, and make sure it has five steps in the application or you ask for these 10 things. It's just go figure out how to reduce this to five minutes. That's the fundamental key.

Jason Knight  18:05  
But this is interesting, because I agree, obviously, with all that I'm just as bought into this stuff as the next person that you talk to. But one of the things that occurred to me then, and it kind of goes back to this kind of fuzzy definition thing is the almost like the definition of an outcome, because, you know, fundamentally, that red button, that's still technically an outcome. I mean, it's not a good outcome, obviously, not in the way that we think about outcomes, but it is still to somebody's up in thinking about the stuff, it's still an outcome, right? Something's still happened. So do we need to maybe have some kind of better definition of what an outcome actually is? Like? You know, for example, it's something that delivers a measurable change for the user, like, is there some kind of almost fundamental foundational work to even describe what an outcome is that needs to happen?

Jeff Gothelf  18:47  
Look, making the button is an output? It's the making of a thing? Yep. Right. It's a thing that we create, it's a feature, a feature is an output. And outcome is what people do, how people's behaviour changes, once we've put this thing in the world. Yeah, now we are making an assumption that by putting out the big red button, people will click it, or people will be happier, and then buy more stuff from us or tell a friend, or whatever it is, there's no guarantee, there's just no guarantee and the pace of change and the change in consumer consumption behaviours and patterns changes so quickly, that it's tremendously risky to say build me this thing, ship it in three months, and guarantee me that it will have these outcomes at the end of it. If you're gonna say, look, what I actually need you to do is I need you to reduce the time it takes somebody to buy a bag of dog food on our website, or we want people to write just make it easier for folks to buy products that they they consume on a weekly basis with us. Now we've got a success criteria that says look, we know that people buy paper towels or dog food every week. And we know that every time they come back they Got to go through the process of signing in adding to cart, et cetera, et cetera, et cetera, et cetera, and then checking out. And so what we'd like to do, having recognised these behaviour patterns in our customers, is we'd like to make it easier for them to subscribe to these products, reduce the friction and doing that, figure out how to do that. Now, the measure of success is not deploy apps subscription feature, the measure of success is make it easier for folks to more regularly buy the things they consume every week. And we know what those things are. And we can measure that your subscription feature doesn't work. Maybe it's text alert with one click purchase link. I don't know. You don't know. Nobody really knows. And it's not to take away from anybody's experience or expertise. We have experienced, we have expertise, we're going to make smart guesses about how to solve for this kind of behaviour. But the reality is that in the overwhelming majority of those cases, your smart guests will be somewhat wrong. Yep. So let's find out as soon as we can, and then improve on that smart guests to achieve the outcome.

Jason Knight  21:04  
Yeah, I 100% agree. Again, this is stuff that I'm working on every day as well. I think that the interesting angle there, though, and it's something that is one of the principles in that book, as well as the idea of customer centricity. Because for some people, the outcome is very much going to be like, well, we want to make X amount of revenue or something like that, which is obviously a terrible outcome to aim for, from a product perspective, like building a feature. But obviously, at the same time, we want companies to make revenue and be sustainable. But getting people away from the only outcome that matters, being this kind of booking next sale or getting into the line going in the right direction. And actually more on how you're enabling that through building things actually make customers and users happy, which I guess it's just again, it goes down to that mindset shift thing that you talked about earlier about getting people to think about things in a different way.

Jeff Gothelf  21:50  
Let's talk about that. Right? So look, you can't fault a company for wanting to make revenue. No, that's right. Right, you can't right. And you can't fault leadership for worrying about revenue. And we're not doing that here. But what we're trying to do is to say, okay, great, you wanna you want to increase revenue by X percent next year, terrific. Let's take a look What behaviour drives revenue, let's break it down. This is an exercise I teach in my product management class. It's an exercise I do with my clients, literally it's we visualise, on whiteboard on a mural board, whatever it is, all of the customer behaviours, that drive revenue. So we start with revenue, what happens just before revenue, well, x, and this happens in this, and then what happens before each one of those activities, and before each one of those, basically an upside down customer journey map that ends at revenue at the end of it. And then we take a look at all those behaviours that are up on the board. And if you if you've done this correctly, and your system is complex enough, you're gonna end up with dozens and dozens of activities on there. And you can say, Okay, boss, listen, strategically, what do we care about in the next 12 months? What's our strategy, because our strategy may be growth, it may be expansion to new markets, and maybe developing new business lines, whatever it is, increasing market share, whatever it is, right, so let's talk about what we care about strategically for the next 12 months. And now let's identify the related behaviours to that strategy, because we're not going to be able to optimise all of these behaviours that we now have on the board. At the same time, we don't have enough people, and we shouldn't even try. So let's focus, using strategy to pick three, four or five of these behaviours, and get our teams working on these three, four, or five behaviours, these outcomes that we know drive revenue, that is a fundamentally important conversation to have a leadership. But there's, there's two things that come out of that. One is you are literally making the visual connection for them by saying, When customers do this, they do this. And then we make money, those three things. And the second thing you're forcing them to say is that you say, look, there's lots and lots of things that we could be optimising for, we cannot do it all. So let's, let's use strategy as the filter for selecting which of these we're going to focus on. And ideally, in an ideal situation, a light bulb goes on and focus on outcomes.

Jason Knight  24:06  
Well, fingers crossed, although I'm pretty sure I'm aware of people where baby that light bulb stays switched off. But, you know, step by step. 

Jeff Gothelf  24:13  
Fair enough. 

Jason Knight  24:14  
But obviously, you've been talking about outcomes a lot. You mentioned earlier about the new book about OKRs. You're obviously doing a course in OKRs. So let's talk about OKRs. And that's obviously one of the most common ways these days that people try to manage towards outcomes. And you yourself said before this call that OKRs are a gateway drug to rigidity and product discovery and good product management. So it's almost like you've got the no hair. It's almost like Breaking Bad the product management edition. But that all sounds great. But we also see a lot of people when they try and go on an OKR journey, just taking out all the old KPIs that they had marked up before, or worse still, like a list of tasks that they already wanted to do. They stuffed that into an OKR tool, and then they get going, and I'm assuming that you're not going to tell me that that gets people hooked on agility, product discovery and good product But there's something more to it than just cramming all your old tasks into a new system.

Unknown Speaker  25:04  
Yeah, you're correct. The answer's. Yes. 

Jason Knight  25:08  
Yeah! Next question!

Jeff Gothelf  25:09  
 Yes. Excellent. Well said Jason. To look OKRs. Let's let's, let's break it down very, very quickly. Because it's really it's, it's a, it's a simple idea that is difficult to implement. And it is literally the way that we get an organisation to start to manage the outcomes, or at least to think about it, and then ultimately drive some of that agility, right. So an objective is the qualitative goal that you're trying to achieve as a team as a business unit, as an organisation and the timeline in trying to achieve it. And right, we want to become the number one destination for online furniture shopping in Europe by the end of 2023, something like that. Yep. A qualitative, aspirational, inspirational, something that gets the teams out of bed every day and off to work. Terrific. The KR is the key results answer the question, how will we know that we're the number one destination for online furniture shopping in Europe by the end of the year? What will people be doing differently from what they're doing today to tell us that we are that number one destination. So people, people will be coming in more than once a year, the average order value will go up by 12% 25% of new customer acquisitions come from referrals, something along those lines, those are the kinds of key results that we're looking for. All of those are measures of human behaviour. All of those are outcomes. That's the key, right? The key is all of this. And so if you recall, the last thing we talked about, right, which is executives care about revenue, right, those KPIs that you typically have today, are going to be revenue, sales, profit margin, those types of things. Terrific. Let's start there. And let's run that exercise that I talked about a few minutes ago, let's break down all of the customer behaviours that drive that. And then the let's use the more tactical customer behaviour metrics, the outcomes as your key results. Now, what's happening here, again, and this is where it gets hard, right? What we just talked about about OKRs, up until this point is the easy part, relatively speaking, is it takes a bit of practice, but everybody can write a good OKR, it's not that hard. The hard part is to give that goal to a team, okay, a team become the number one destination for online furniture shopping in Europe by the end of the year. And we want you to drive referrals by 25%, increase average order value, and half people visit, half our customers active buying customers visit at least twice a year, something like that. Terrific. Go. And this is where it gets hard, because teams will literally give you a blank stare, because you didn't tell them what to do that you didn't tell them what to make, you gave them a goal where they helped define that goal for themselves. And now they don't know what to do, because what they're used to doing is following your orders, make this update to the website, make it read, get it done by Friday. And so this is where things get interesting for everybody, because the teams are not sure what to do. So they need to know how to do product discovery, right? So how do we discover the best combination of code, copy, design, value proposition, business model, pricing model, whatever it is, that gets people to change their behaviours in this particular way. And they need to know how to do that. A lot of teams don't know how to do that. And they need to be able to do that a lot of organisations keep their teams from doing product discovery, oh, yes, as well. And the managers on the leadership side, get super anxious. Because they don't know what the team is working on, because they didn't tell them what to work on. And so it's kind of like, there's two types of anxiety here that teams don't know exactly what to do, or how to do it. And their bosses who are terribly afraid that somebody will come to them and say, Hey, what are your teams working on? And I don't know, it's not a good answer.

Jason Knight  28:47  
That's gonna terrify some people. 100% is gonna terrify them, you kind of touched them yourself. But it's also going to maybe time limit the amount of time they're prepared to put up with that uncertainty as they see it. So like, how do you get past that barrier of like, oh, yeah, well, we tried it. We weren't sure. We didn't like it, we went back.

Jeff Gothelf  29:05  
This happens a lot, right? With any new way of working in a new process. People will will head down a particular path. They'll struggle with it, they'll give up and they'll fall back on what they know. Yep. And that makes sense, right? And that's why people do Scrum sucks and agile sucks. Design Thinking sucks. And lean UX sucks and everything's everything's terrible, right? And yeah, look, a bad implementation or a bad experience will sour your views on things? The question and this is where truly mature organisations succeed. The question is to do retros on these like real, like real honest to goodness, retrospectives, where we figure out what why didn't it work? That maybe we weren't set up technologically to deliver the learnings in time for us to adjust course. Okay. How do we solve for that? Maybe we didn't set expectations properly with the leadership team about what we'll be reporting on. And that was an issue. Maybe we didn't train the teams and product discovery. Who knows right? This An infinite number of reasons why things might have gone sideways. I think if you've given something a shot, and it failed, at least you will retrospective to understand why it failed. And if the reasons that have failed are solvable, I would recommend you give it another shot. I'm the last person who's religious about any of this stuff, right? Yeah. I don't subscribe to capital letters, right? Like, I'm not really I believe in agility, right. I don't care if you're agile, like if you're practising agile capital A, I believe in in organisations. Agility, I believe in customer centricity. I believe in continuous learning, right? You want to if you want to brand name that and I have called the Lean UX. Terrific, but if you want to call it anything else, that's fine. Sometimes, right? Sometimes it's the brand name that gets people hung up, and you'll find organisations that create their own brand names for stuff. Yeah. Did you hear this all the time? He was out fast works at GE, right. It wasn't lean startup. It was it was fast works. What was it called at ing ing had a name for it to some acronyms like spectrum or? I can't recall. But they were looking at. Yeah, but an ing right. They had to rename it. Because there's a lot of baggage that comes with this stuff these days Agile and Scrum and lean startup and design thinking and OKRs. But really do the retro understand why it failed. I can't tell you honestly, how often and it's not a majority of the time, but it's enough to be able to talk about it. Were the person who was brought me in to teach OKRs, Lean UX, product management, whatever it is, managing outcomes in general, ends up being the problem to adoption, right? The person hired. And they don't see it. Yeah. And that's, that's really, really tough love that you've got to give to those folks sometimes

Jason Knight  31:56  
reminds me of something. I think I was talking to John Cutler about this a while back. And one of the things he said is that some of the people out there that will read these books, the books like yours books, like so many other books out there. And they'll be nodding along and saying, oh, yeah, that's the way we should work. That's the way we do work. And then you talk to them. And it turns out that they're absolutely not working like that. And they're kind of almost I don't know, if it's like blinkers or blinded or just the, they have an overly optimistic view of how there's obviously a number of different ways that it can play out. But this idea that it's easier to kind of look at something and say, oh, yeah, that makes sense than it is to actually do it and change your own mindset as well. So it's definitely an interesting one.

Jeff Gothelf  32:33  
I see it all the time, right? I have an inbound lead. And we do a little discovery work discovery call to understand how to structure the class, how to custody, if there's customization needs to be done. And you'll be talking, this happens, I'd say 20% 25% of the time, we'll get a client come in, and they'll say, I said, great. So tell me how you work and like, oh, well, we declare our assumptions, right hypotheses, we run experiments. We work in short cycles, we do retros we build learning activities in every sprint. That's great. So what why do you need me? Sounds like you got this, like, well, we struggle here and there. I was like, okay, so this will largely be a recap for you a review, like, Yeah, that's fine. Yeah. And you get in there, and sure enough, it's a it's a disaster from from everything.

Jason Knight  33:18  
But if we look at, say, measure what matters, which is obviously one of the classic books about OKRs kind of talks about the Google way, it's got Bondo in it. So it's got to be good, right? That's talking a lot about organisational OKRs that cascade down to Team OKRs. They cascade down to individual OKRs, and one set of tapes into their cubicles, everyone knows what everyone's doing. But when I interviewed Christina woodcare, about this a while back, she said that she thought that individual OKRs in particular, are not a great idea at all, because it's all about the teams. And it should all be about the team's not individuals and you kind of introducing too much complexity by having like individual OKRs that specific people have to do, which may or may not be in conflict with other OKRs that they've set for teams and stuff like, do you buy into this individual key idea? Or are you very much a team? Okay, I type of guy,

Jeff Gothelf  34:05  
Team OKRs. That's where I am right at the individual OKR. Let's start the beginning. OKRs are a team based goal setting framework, that's what they're for. The second you take it down to the individual level. Remember, the objective is is a qualitative aspirational goal. And the key results are measures of human behaviour. Now what typically happens in individual OKRs and I've seen this in organisations, they'll say my objectives is to become a 10x engineer in the next 18 months. Which look that's a qualitative aspirational inspirational goals. Yep. Terrific. Okay, good. And what's your what is your results? I'm going to attend three workshops, read 10 books, you know, and take. Get my Master's in Computer Science. Okay, great. Now that you've completed those tasks, those are not changes in human behaviour. Those are tasks. Yep. How We know that you're a 10x engineer, what are people around you doing differently. And this is where it gets hard, I do not recommend individual OKRs. But if you're going to, if you're going to do it, which I don't think you should, then the key results need to be things like 80% of the people who work with me would work with me again, I think I could pass that 170 5% of, of my peers would say that I am a go to the go to resource for any technical issues, whatever it is, but it's it's things you have to impact the behaviour of others anytime that your key result is your own behaviour. First of all, it's a task number one. Second of all, it is a it's game bubble. Yep. Right? Oh, I read 10 books. And third of all, there's no indication that you actually got anything out of the activity. So just just don't don't do individual OKRs.

Jason Knight  35:55  
Fair enough, we'll go and take some notes after school and work out who's doing that you talked before this, about how managing to outcomes changes everything. And then in brackets if you let it. But it's part of the problem with adopting approaches like this is that some companies or that some company leaders, they kind of don't really want to change everything, they kind of just have this idea. We talked about it earlier, the fixed mindset, maybe this is the way it should be. And maybe they look at OKRs, because it's become fashionable. It's in some books, Google did it. And they're like, well, actually, yeah, we don't really want to change much about what we do. We believe that we're doing kind of the right thing. And we just want to kind of do that thing better. Like, is that a big problem?

Jeff Gothelf  36:37  
Again? Yes. But yeah, but let's dig into it. I'll tell you a story. In this case, I had a client recently, who I was super excited to work with, because I don't get to work with these kinds of clients. Usually, this was a global organisation. It was a nonprofit focused on improving the overall health of people in developing nations that go, absolutely fantastic goal, a fantastic, diverse global organisation with amazing aspirations, right, and really like trying to make a significant impact on the health and well being of folks in developing in the developing world. And so they they brought me in to teach them OKRs. And it was a struggle, because they're used to working with tasks lists of tasks. And that's how you measure progress. And that's how they measure whether success and then also their timeframes were much, much longer that right. So if you're going to have an impact on the health of Brazil, for example, it's not going to be in two weeks. Exactly. You might have to work for three Sprint's to make that happen. And so and so there was a real difficulty. And and look, I'm not gonna, I'm not going to tell you that, you know, I struggled a bit as well with it. But it was really interesting. It's an interesting challenge. How do we make this work in this context with with these types of challenges, and no matter what I tried, no matter how, again, I was brought in from the senior, the senior leadership team, no matter what I tried to do, and I explained the concept over and over and over again, they wrote some OKRs. I gave them feedback, we rewrote them for them, I could kind of get here's what I'm looking for that type of thing. They could not get out of this mindset, well, what are we going to do? Like, what are the tasks? And if I don't do the tasks, and somebody will be mad at me, and then at one point, I was talking to the leader of the CEO of the organisation, and he was pushing back on me, he's like, Yes, but what are the teams going to be doing? What are they like? How do we, how do I measure what they're doing? And I said, Look, we've talked about OKRs, a bit, you know, you and I are with a team solution team. Why are we doing this? Right? Why are you doing this? Like you clearly, there's a lot of organisational pushback. And he literally said to me, I have no idea. I have no idea why we're doing this. Wow. And I believed him. And it really I felt like and I said, Look, we we've like you said, I read measure what matters. We've got a couple of kind of high profile tech folks on the team, who recommended this seemed like the right thing to do. What I'll be honest with you, I don't know why we signed up for this. And I think there's a lot of that, right? It's kind of like, We saw this with agile, right? The sort of like, well, they're doing Agile everyone's doing, we have to be doing Agile, and we started with Lean Startup, but they're gonna do anything startup, we have to do Lean Startup. I think the same thing is happening here. I think it's a bit of a cargo cult mentality where it's like, everybody's doing it. So we're going to make the same noises and motions, but honestly, I've no idea why we're actually doing this. And I was thrilled, honestly, to hear him say that. Yeah. Because that at least allows us to now move forward from a shared point of honesty, and humility. Yeah, that was a big turning point. I can't tell you I was overwhelmingly successful after that, but at the very least, we were able to say Okay, then let's talk about why we're doing this and see if it makes sense for you or not.

Jason Knight  39:55  
That's really interesting. I think I saw one social media post with... like OKRs, were just a psyops by Google to make all up and coming startups fail, because they would just copy them blindly and not actually get to do any of the stuff. And that's the thing that when I was chatting to someone about OKRs, recently, and they were saying, Well, you know, can OKRs work in this situation, or that, you've talked about it a lot yourself, it's not so much about the OKRs themselves, they almost like the output itself of the process that you've gone through to get there, rather than just putting it in that form that fixes everything. So I do think it's an interesting one. Right? So you, in some senses kind of didn't make any progress in that particular situation. And of course, you know, you've mapped out why, but in general, when you're going into companies wanting to change that mindset, and there was a bit more appetite for that, and actually do know why they're doing it, but they just need to work out how to do that, and how to change and maybe change some people in their organisation that kind of hold out. So are there any approaches that really work for you, like when you go in there that really helped a bit this in with companies? Or is it so diverse, depending on the company that it's impossible to be kind of generic about it?

Jeff Gothelf  41:00  
The thing that I do is, and this, this comes back to the conversation that we had earlier, is I make no assumptions that anyone has any idea what I'm talking about? Basically, somebody's does, right. And maybe most of them do, it's clearly cuz somebody hired me and brought me in. But I make no assumptions that people understand what OKRs are, why they, why we're doing them, why it's important. And so I always start from zero and I set the stage. For them, I explain why I believe this is extremely powerful. And that it's a simple idea, I can explain to you in five minutes, that's difficult to implement. But let's go through it. And let's see where we get out. Now, obviously, the context will always matter. And the nice thing about the experience I've had the last couple of years, is I've managed to do this in a variety of concepts. So if I'm going into a b2c digital product team situation, it's a no brainer, like it's the easiest situation to be in, that people generally get in. But if they don't, selling them on the fact of continuous improvement, continuous learning, continuous systems, you know, software, you're you're in the software business, that type of thing is super easy. But I've had clients before in retail, I've had a shoe company, as a client, which is really interesting that they sell online, those folks super quick. But we had shoe designers and folks, a buyers have materials to make shoes in there as well, and people who open stores in there. And that becomes a really interesting context as well. And so it's good to get that that information upfront there. And then to bring in that experience and say, Look, I've worked with retail folks, before I've worked with folks, let's talk about that. Let's talk about why you do what you do, who you do it for and how you measure success. And so it's really just starting from zero is, is the way to make it happen.

Jason Knight  42:50  
If all else fails, if and get Bono to come in and sing him a song about OKRs or something as well.

Jeff Gothelf  42:56  
Ideally, ideally.

Jason Knight  42:59  
And where can people find you after this if they want to talk to you about being lean, or doing OKRs better? Or maybe argue a little bit about your definition of design thinking?

Jeff Gothelf  43:09  
The easiest places to find me on my website, https://jeffgothelf.com/ and you can sign up for my newsletter there. And then also LinkedIn, please connect with me on LinkedIn. I'd love to see you there as well.

Jason Knight  43:21  
All right, well, I'll make sure to link that all into the show notes. And hopefully you'll get a few people heading in your direction to find out more Terrific. Well, that's been a fantastic chat. So obviously really happy we could spend some time talking about some important topics and hopefully inspire people to think about hotels in different way. Obviously, we'll stay in touch but as for now, thanks for taking the time.

Jeff Gothelf  43:38  
My pleasure, Jason, thanks so much for having me.

Jason Knight  43:42  
As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to hop over to white knighting product.com Check out some of my other fantastic guests, sign up to the mailing list or subscribe on your favourite podcast app and make sure you share your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest but as for now, thanks and good nights